arXiv:l 502.03407V 1 [cs.CR] 11 Feb 2015 


Albatross: a Privacy-Preserving Location Sharing System 


Extended version of ASIACCS 2015 paper 


Gokay Saldamli 

Samsung Research America 
665 Clyde Avenue 
Mountain View, CA 94043 
gokay.s@samsung.com 


Richard Chow 

Intel Corporation 
3600 Juliette Lane 
Santa Clara, CA 95054 
richard.chow@intel.com 


Hongxia Jin 

Samsung Research America 
665 Clyde Avenue 
Mountain View, CA 94043 
hongxia.jin@samsung.com 


ABSTRACT 

Social networking services are increasingly accessed through 
mobile devices. This trend has prompted services such as 
Facebook and Google+ to incorporate location as a de facto 
feature of user interaction. At the same time, services based 
on location such as Foursquare and Shopkick are also grow¬ 
ing as smartphone market penetration increases. In fact, 
this growth is happening despite concerns (growing at a 
similar pace) about security and third-party use of private 
location information (e.g., for advertising). Nevertheless, 
service providers have been unwilling to build truly private 
systems in which they do not have access to location infor¬ 
mation. In this paper, we describe an architecture and a 
trial implementation of a privacy-preserving location shar¬ 
ing system called Albatross. The system protects location 
information from the service provider and yet enables fine¬ 
grained location-sharing. One main feature of the system 
is to protect an individual’s social network structure. The 
pattern of location sharing preferences towards contacts can 
reveal this structure without any knowledge of the locations 
themselves. Albatross protects locations sharing preferences 
through protocol unification and masking. Albatross has 
been implemented as a standalone solution, but the tech¬ 
nology can also be integrated into location-based services to 
enhance privacy. 

1. INTRODUCTION 

Smartphones are likely to become the fastest-spreading tech¬ 
nology in history, beating even electricity and television. Ac¬ 
cording to a March 2012 PEW report [2B], nearly half (46%) 
of American adults were smartphone owners and by 2017 
three billion of the estimated nine billion worldwide mo¬ 
bile subscriptions will use a smartphone. With the spread 
of smartphones, applications with location capabilities will 
increase in popularity. Location-based services (LBS) typi¬ 
cally offer benefits such as precise navigation, location-based 
discount coupons, or easy information sharing through fea¬ 
tures like social check-ins. These services are likely to reach 
hundreds of millions of users over the next couple of years 
with the help of smartphone market penetration. 

In this paper, we concentrate on a particular LBS, social lo¬ 
cation sharing. With services such as Foursquare [5], users 
can checkin and share their current location with contacts. 
Status updates which include location has now become stan¬ 
dard on general social networks such as Facebook and Google+. 
Applications such as Google Latitude [B], Highlight E. Ap¬ 
ple’s Find My Friends [3j, and (reportedly) Facebook [2] go 


a step further by sharing location with friends even while 
running in the background. 

According to another PEW report [29], 18% of all smart¬ 
phone owners and 10% of all adults share location. Foursquare 
claims to be used by nearly 30 million people worldwide [4] . 
Such growth has not come without concern; in many ways, 
location sharing has been a poster child for online privacy. 
For instance, the site PleaseRobMe.com was launched to list 
people who were not home according to their Foursquare 
checkins [4[. According to [10], over 30% of smartphone 
users have turned off the location tracking feature on their 
cell phone because they were concerned that other individ¬ 
uals or companies could access that information. 

The work described in this paper attempts to address the 
privacy concerns of location sharing. We describe the archi¬ 
tecture of Albatross, a location sharing application designed 
for privacy. The system is named after one of the most mo¬ 
bile of animals: “Albatrosses range over huge areas of ocean 
and regularly circle the globe.” ]Tj. 

One goal of Albatross is to hide the userSs location from 
the server and yet allow flexible sharing with other users. 
Albatross can be used for sharing users’ whereabouts with 
only selected contacts, such as close friends, family members 
and colleagues. At the same time, another goal of Albatross 
is to hide the user’s privacy policies for his location. These 
policies may be even more sensitive than the location itself, 
as the policies (i.e., user’s sharing preferences) can imply 
who is favored by the user and who is not. We hide or 
mask a user’s sharing preferences by using a meta-protocol 
that hides our individual protocols. We also obscure traffic 
activity through dummy sharing events. 

Albatross supports an asynchronous sharing model, where 
Alice can share her location or checkin to an offline contact 
who can then see Alice’s location after coming online. Nat¬ 
urally, Albatross can also be used for automated periodic 
sharing or “tracking,” say sharing location with a spouse. 

As Albatross never shares the location information with the 
server, it is markedly different from current location sharing 
services such as Foursquare and Google Latitude. All of 
our protocols protect users’ location from the server, and in 
addition regulate and conceal the patterns of sharing among 
users. 
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1.1 Contribution 

Albatross is a location-sharing system composed of several 
simple cryptographic protocols that allow users to share 
their locations with their contacts privately. Albatross keeps 
key features of a typical location-sharing service while pro¬ 
moting privacy. The following are the two main goals: 

• Location privacy. Users share their location infor¬ 
mation only with their contacts; location data is al¬ 
ways encrypted and never visible to the service provider. 

• Social Network Privacy. By virtue of routing all 
traffic, a service provider can typically observe a user’s 
active social network and temporal habits. For exam¬ 
ple, which contacts a user shares most often with and 
which contacts a user shares with at different times 
of day. Albatross protects against traffic analysis by 
protocol hiding and adding dummy traffic. 


Albatross is practical in terms of performance. All of our 
protocols are lightweight, using symmetric key encryption, 
and can easily be run on a mobile phone. Nevertheless, Al¬ 
batross does introduce considerable overhead compared to a 
non-private, trusted server system. Hence, we have empha¬ 
sized efficiency in our design and made choices that reduce 
computation and storage when possible. One example is 
the introduction of a novel grid scheme in Section [5] that 
requires only one protocol run compared to multiple runs in 
other schemes, albeit at a small reduction in privacy. We 
implemented Albatross as an Android application for smart 
phones and measured performance overhead of the system. 
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2.1 Example of Google Latitude 

In general, users run a mobile application that connects to 
the location sharing service website. Through the applica¬ 
tion, the user can checkin or announce his location to some 
set of his contacts. Two users can become contacts by mu¬ 
tual agreement; for instance, one user can invite another user 
to be a contact, which can then be accepted. We briefly 
outline the functionality of Google Latitude [B], which is 
fairly typical of location sharing services. Figure Hal shows a 
screenshot of checkin. Note that in Google Latitude a user 
can checkin to a fake location (see Figure [Tbll . 
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(b) Retrieval of friend lo¬ 
cations 


Figure 2: Friends in Google Latitude 


For each contact, a user may set a different preference or 
granularity of location sharing. See Figure [5a] for the ex¬ 
ample of Google Latitude. A user can share his exact lo¬ 
cation, an approximate location, or not share location at 
all. Finally, using an interface such as Figure [2171 a user can 
retrieve or see the locations of his friends. 


Note that the locations of users are visible to Google Lat¬ 
itude. Furthermore, the sharing activity and granularities 
for each user are also available. Hence, Google Latitude can 
reconstruct not only users’ movements over time but the 
whole social network. 


Check in here I 

(a) Checkin screenshot (b) Location reporting 

Figure 1: Location sharing with Google Latitude. 

The rest of this paper is organized as follows. Section [2] is 
a brief introduction to location-sharing services. Section [3] 
describes our privacy model and goals. Section [I] overviews 
the base location-sharing and cryptographic building blocks 
used to construct Albatross. Section [S] describes our grid 
and cell system. Section [6] details the main Albatross proto¬ 
col, one that incorporates the basic protocols of Section [5] 
Section [3 describes our prototype implementation. 


2.2 Location Sharing Granularities 

Location sharing preferences can be quite diverse; for in¬ 
stance, users may want to share their exact location, an ap¬ 
proximate location (e.g., city-level as in Figure I5al in Google 
Latitude), choose to be invisible (“Hide our location” in Fig¬ 
ure S3, or provide a fake location (“Set your location” in 
Figure CB. Each choice is called the granularity of the 
location-sharing. The granularity of sharing may vary with 
the particular contact. For instance, a user may want to 
share their exact location with family, an approximate lo¬ 
cation with close friends, and be invisible to everyone else. 
These preferences may also change from moment to moment. 

Albatross offers a set of granularities {available, approxi¬ 
mate, nearby, invisible, fake} composed of the most common 
preferences. We summarize the meaning of these granulari¬ 
ties as follows: 



2. LOCATION SHARING SERVICES 

We provide some background on location sharing services. 
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• Available: share exact location 

• Approximate: share approximate location, e.g., the 
city or region 

• Nearby: share approximate location only if the contact 
is nearby 

• Invisible: share nothing, also known as hiding 

• Fake: share a fake location. This might be an exact or 
approximate location. 

3. LOCATION-SHARING PRIVACY DEFI¬ 
NITION 

A location-sharing service manages events of the following 
form: User A shares timestamped location information (of 
some granularity) with User B. We assume the service relays 
traffic between User A and User B and hence knows the time 
of the sharing event. Historical data for the service consists 
of a record of all events with timestamps. 

Sharing events may be encrypted so that the service cannot 
necessarily determine the location or granularity of the shar¬ 
ing event but does know the parties involved in the sharing 
event. We also assume the possibility of “dummy” sharing 
events that do not convey any information from User A to 
User B. The service cannot distinguish between an actual 
sharing event and a “dummy” event. Hence, despite the 
service observing all the traffic, the service does not know 
whether a user has actually shared location information with 
another user. 

Assuming the service has all historical data to analyze, ideal 
privacy for users of a location-sharing service consists of the 
following: 

• At any time, the service knows nothing about any 
user’s location. 

• At any time, the service or any other users know noth¬ 
ing about whether any user is online. This implies a 
lack of gaps in the event stream for any user. Such 
a gap may imply undesirable inferences, such as an 
airplane flight. 

• At any time, only users which User A has shared with 
know about A’s location. These users know User A’s 
location only to the degree of granularity specified. 

• The service learns nothing about a user’s contacts. In 
particular, the service learns nothing about a user’s 
social circles, e.g., who he commonly shares with and 
to what degree. 

In practice, ideal privacy is difficult to achieve since in our 
architecture all traffic goes through the server. A user’s 
active contacts would eventually be revealed through traffic 
analysis, unless a large amount of dummy traffic is sent. In 
our design we chose to reveal each user’s contacts to the 
server. This seems an acceptable tradeoff for scalability, as 
securing location is the primary goal and the inner structure 
of each user’s contacts (e.g., close vs. not-so-close friends) 
remains protected. 


Likewise, we chose not to protect temporal patterns from the 
server. This is, however, an interesting direction for future 
research. A system where every device appears active to 
the server is possible; one scheme would involve an auxiliary 
proxy (for instance, in the cloud or a desktop at home) that 
funnels traffic and covers up for the device if it is offline. 

3.1 Adversarial Model 

Before we discuss the privacy goals of Albatross, we outline 
the adversarial model. We assume an untrusted server, but 
a server that is Honest-but-Curious. This assumption is re¬ 
alistic, as argued in m violating the honest-but-curious 
model risks damage to a service provider’s reputation. The 
server correctly routes protocol messages, but does not at¬ 
tempt to create fake users or collaborate with existing users. 
In particular, for our VPET protocol (see Section POl) . server 
collusion with User B would reveal User A’s location. 

We see data sub-poenas, hacker break-ins, or inadvertent 
data release as examples of threats on server-side data. These 
are the main motivation for the Albatross system. Threats 
from users trying to infer the location of another user also 
must be considered, although for the most part these threats 
are similar to threats in existing systems. In the Alba¬ 
tross system, the attacker would have to be a contact of 
another user to get any information at all. However, for the 
“nearby” location granularity (in which a user reveals loca¬ 
tion to nearby contacts only), there are new privilege escala¬ 
tion attacks, where an attacker granted the nearby location 
privilege tries virtually placing himself in many locations in 
order to narrow down the possible location space of the user. 

3.2 Privacy Goals of Albatross 

Our privacy goals improve upon existing systems in that 
the server remains oblivious to users’ (1) locations, and (2) 
sharing granularities or circles. Specifically, our goals are: 

• PI (Server): The server learns nothing other than 
the set of contacts for each user and which users are 
online in any given time interval. The server does not 
learn anything about a user’s social network structure 
(other than the set of contacts). The server does not 
learn the granularity of shared location. 

• P2 (User): A user’s contacts learn only the location 
granularity that he intends for them to know. This 
goal is no different from current location sharing ser¬ 
vices such as Google Latitude. Furthermore, his con¬ 
tacts cannot infer when a user is offline. The reason 
is that when User A is invisible to User B, User A 
wants there to be uncertainty as to whether A is being 
purposefully invisible or simply offline. 

Note that network and device information may reveal infor¬ 
mation about a user; for instance, the IP address may reveal 
an approximate location using a geo-location database. Sim¬ 
ilarly, a mobile carrier will have location information on a 
device from the cell towers it connects to. These concerns 
may be mitigated through use of an anonymizing network 
and a proxy device, but we do not directly address these 
concerns in this paper and assume the server’s information 
consists solely of our protocol information. 
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4. BASE PROTOCOLS 

We start with the case where User B shares his exact lo¬ 
cation with User A at a certain time; in other words, User 
B is checking in to User A with the preference of “avail¬ 
able.” User A then retrieves User B’s location information, 
perhaps at some later point in time. We hide this sharing 
from other contacts and the server with the following sim¬ 
ple asynchronous protocol. The same protocol is used if B 
shares an approximate or a fake location. 

We assume the existence of a shared key Jzab between users 
who are contacts A and B. This shared key can be created 
at the time a user adds another user as a contact. If a pub¬ 
lic/private key pairs is in place on the device, say through 
an existing PKI set up by the social network, this shared 
key can be formed using the Diffie-Hellman key-exchange 
protocol. SocialKeys has been proposed as a lighter weight 
alternative [21] . 

4.1 Private Sharing Protocol (PSP) 

With PSP, the location information - either approximate, 
exact, or fake - is simply encrypted so that it remains hid¬ 
den from unauthorized users and the server. Let A-Alice 
and B-Bob and S-Server be the three parties involved in the 
protocol. Table Q] gives the basic parameters used in PSP. 

Table 1: Basic protocol parameters 


xa and xb 

Location information for A and B respectively 

E 

Symmetric encryption function 

kAB 

is the key shared by users A and B 

ctr 

a counter value set to zero in the very first 
handshake between A and B and incremented 
whenever new masking keys are needed. 

ki,k2 - ■ ■ 

parts of the encrypted ctr value 


Figure [3] shows how the location information, xb is en¬ 
crypted by user B so that it remains hidden from the server. 
The encryption is performed by masking the location with 
the output of the pseudorandom function (PRF) E. Since 
the bit size of the mask is determined by the location pre¬ 
cision, a single encryption can be used for multiple sharing 
instances. For instance, if the location information is is 
presented by 32-bits and E is 128-bit block cipher such as 
AES, both parties would perform a single encryption of ctr 
and reuse the four different blocks of the ciphertext ki. This 
is equivalent to a single encryption after every four shar¬ 
ing instances. Note that the Server is passive, i.e., it only 
transmits the messages in this protocol. 



k\ = Ej. (ctr) 



k\ = E k (ctr) 
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Figure 3: Private sharing protocol 


mation with only their nearby contacts (e.g., within a circle 
of radius r) who have made their location visible (available, 
approximate, or nearby). Compared to unconditional shar¬ 
ing in PSP, this sharing has the requirement that users need 
to know their contact’s location or proximity before sharing 
their own location. For instance, if user A receives location 
information xb from user B, he may determine that user B 
is nearby and decide to share his location information xa- 
In fact, this is a natural interaction in a location sharing ser¬ 
vice. Hence, PSP can still be used after checking a contact’s 
location or proximity. 

However, proximity sharing is a bit more complicated if two 
users want to share their locations to each other only if the 
other is nearby. In this case, since both parties do not have 
any prior location or proximity information PSP is not use¬ 
ful. There are more sophisticated solutions available: 

4.2 Vectorial Private Equality Testing (VPET) 
Protocol 

We describe in Section E2 the relationship between private 
proximity sharing and the so-called Private Equality Test¬ 
ing problem (PET). Basically, one can subdivide the earth’s 
surface into a grid and test equality of belonging to the same 
grid. PET is also known as ’’Socialist Millionaire Problem” 
m where two millionaires want to determine whether their 
wealth is equivalent or not, without disclosing any informa¬ 
tion about their riches to each other. 

PET is a well-studied problem in the literature. Various 
aspects and use cases of PET were considered in a num¬ 
ber of studies including [14] |8] [28] [21]. The majority of 
these solutions are two-party protocols using computation¬ 
ally intensive cryptographic primitives such as homomor¬ 
phic, commutative, or public-key encryption. Nevertheless, 
there are three-party protocols such as EUI24] that use com¬ 
parably lightweight symmetric-key primitives requiring far 
less communication. In Albatross we use VPET [24], one 
of these recently proposed protocols for sharing locations to 
only nearby users. Naturally, using a different PET protocol 
would not effect the overall system. For completeness, we 
briefly describe the VPET protocol here. 



The flow of the protocols presented in Fig. |4] Assume that 
Bob wants to share his private location xb with Alice. In 
VPET, location values are mapped to vectors using a vector- 
ization process and these vectors are masked by the following 
values 


In some cases, users might want to share their location infor- 


(s, 8) = E kAB {ctr) 
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Bob arranges the output of the PRF, E, in a way that s 
represents a vector having random entries and 9 represents 
a rotation angle. Next, Bob computes: 

b — vR(xb, 9) + s 

where r is a non-zero random number and s is taken from 
the E function. He sends b and ctr to the server. 

Alice, in order to compute whether Bob is nearby, first 
queries the server to obtain the latest value of ctr from Bob. 
Alice aborts if the ctr received from the server is not fresh, 
otherwise Alice computes ( s,9 ) = Ek(ctr) and a unit vec¬ 
tor u perpendicular to xa ■ Alice then blinds u by using 
the rotation function R, where 9 is pseudorandom value by 
definition. Alice sends a = R(u, 9) and ctr to the Server. 

The Server matches the messages having the same ctr value 
from Alice and Bob, and performs a single inner product 
operation giving m = ( a,b ), then sends m to Alice. 

m = (a,b) = (R(u,9),rR(xB,9) + s) 

= r(R(u,0),R(xB,9)) + (R(u,0),s) (1) 

Since R is an angle preserving map, R(xb,9) is perpendic¬ 
ular to the vector R(u, 9) if the private values (vectors) of 
Bob and Alice are same (i.e., xa = xb)- Notice that in this 
case the inner product on the left of Eqn. © vanishes and 
only (R(u, 9), s)) remains. Alice can compute this value as 
it does not contain the blinding r. Therefore, Alice com¬ 
putes (R(u, 9), s)), and if she finds that m = {R(u, 9), s )), 
she learns that she has the same private vector as Bob. 

4.3 Approximate and Fake Location Sharing 

At the protocol level, approximate and fake locations are 
shared in the same manner as actual locations, simply en¬ 
crypted and routed through the Server using the PSP Pro¬ 
tocol. The Albatross system does not guide or make sug¬ 
gestions to the user on what to use as an approximate or 
fake location. We note, however, that this is an interesting 
area for future work. Realistic faking especially is ripe with 
challenges, as the fake locations should be realistic to adver¬ 
saries with potentially a great deal of auxiliary information. 
Previous work in faking of locations include HZIIEIBS]. 

4.4 Protocol Chart 

The chart in Table [2] gives the use of the protocols PSP and 
VPET with respect to the user’s sharing preferences. 

Table 2: Albatross’ protocol chart. 


A => B 

available 

circle 

approx 

nearby 

invisible 

fake 

available 

PSP 

PSP 

PSP 

PSP 

PSP 

PSP 

circle 

PSP 

PSP 

PSP 

PSP 

PSP 

PSP 

approx 

PSP 

PSP 

PSP 

PSP 

PSP 

PSP 

nearby 

PSP 

PSP 

PSP 

VPET 

n/a 

PSP 

invisible 

n/a 

n/a 

n/a 

n/a 

n/a 

n/a 

fake 

PSP 

PSP 

PSP 

PSP 

PSP 

PSP 


A => B shows how User A shares her location with User B. 
For instance, the first row is read as available User A shares 
her location (only) with B using protocol PSP, no matter 
what User B’s status is. 


5. GPS DATA AND GRID SYSTEMS 

In this section we give background on GPS coordinates and 
grid systems for Albatross. We describe a novel grid scheme 
that provides additional efficiency compared to existing schemes, 
but at a small reduction in privacy. 

5.1 GPS Coordinates 

When using PSP, one directly shares the location data as 
captured from the device, say, by the GPS system. In typ¬ 
ical applications, acceptable precision can be achieved by 
packing GPS coordinates (a latitude-longitude pair) into 8 
bytes. Hence, in Albatross we allocate 8 bytes for each ex¬ 
act location and truncate input from the GPS system. Ta- 
ble[3]gives the relationship between a given precision and its 
equivalent physical distance on the earth’s surface. 

Table 3: Precision used in GPS data. 




fractional digits 



2 

3 

4 

5 

total bits needed 

31 

37 

43 

51 

distance 

on latitude 

1,117 m 

111 m 

11 m 

1.1 m 

distance 

polar circles 

444 m 

44 m 

4.4 m 

0.4 m 

on 

tropic circles 

1,021 m 

102 m 

10 m 

1 m 

longitude 

equator 

1,113 m 

111 m 

11 m 

1.1 m 


5.2 Private Equality Testing and Grids 

In principle, the neighbourhood of a location is defined by a 
circle and the proximity testing problem is to test whether 
a contact is inside or outside of the circle. In other words, 
checking whether a user is nearby or not consists of obtain¬ 
ing the location of the user (e.g., via GPS), calculating the 
distance to this location, and testing if the distance is lower 
than some radius r. As pointed out in | 21 |. this ideal def¬ 
inition suffers from a triangulation attack that reveals the 
exact location by stepping across the circular boundary at 
two different points. Moreover, if the location values are 
encrypted, the distance calculation would need a costly ho¬ 
momorphic encryption scheme. 



Figure 5: Direct distance computation versus approximation 
methods. The green user is in both the circle and grid cell 
and is correctly considered as nearby. However, both of the 
red users are falsely detected. One of the red users is not in 
the cell and is thus considered as far away (although he is 
in the range of the circle). Similarly, the other red user is 
considered as nearby because he is in the grey cell but he is 
not in the range of the circle. 

Hence, as in m, we reduce private proximity testing to 
private equality testing (PET), using a grid or tessellation 
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of the surface of the earth. Each grid cell has a unique 
identifier, and the users can compare the identifiers of the 
grid cells using a PET protocol. Grid cells do not necessarily 
match with circular neighbourhoods, so the proximity test 
is less accurate. For example, in Figure O a user (drawn in 
black) wants to share his location in the range of a circle 
while the gray area covers his residing cell. 

One way to improve the accuracy is to use more and/or 
smaller cells to approximate the area of the circle as in Fig¬ 
ure [6] This approach increases the number of cells to com¬ 
pare, as a user must run a PET protocol to compare grid cell 
identifiers for each of the cells making up the approximate 
disk. 



Figure 6: Grids approximating the disk. Observe that (a) 
needs 9, (b) needs 29, and (c) needs 3 cell comparisons. 
Moreover (b) is the most and (c) is the least accurate. 


The approximation can be done in different ways, using 
square cells, hexagonal cells, as well as other shapes, or 
overlapping layers of cells |211 1221 1281 I20| . While all ap¬ 
proximation based solutions are inaccurate, certain shapes 
can approximate a circle using fewer cells than others. 


5.3 Albatross Grids and Cells 

The Albatross system does not depend on any particular 
grid scheme. Nevertheless, we have chosen to construct our 
own grid scheme which is highly efficient (with only one 
PET protocol run) but with a potential reduction in privacy 
compared to other schemes. To describe our scheme, we 
deviate from standard terminology slightly. In the literature, 
a grid cell means an element of the grid tessellation. In this 
paper, we say the grid is the tessellation of the surface of 
the earth into approximate disks. Each element of the grid 
is further subdivided into cells. A grid element is the union 
of cells approximating the circle. 



Figure 7: Grids with hexagonal cells. 


In order to approximate the area of the circle with cells, each 
location can be tagged with a grid ID and a cell ID. Assume 
that the grid consists of a collection of cells that cover the 
location space without overlap. In other words, grids have a 


regular shape such that there is no location left uncovered. 
For instance, grids such as (a) and (c) in Figure [6] can cover 
the location space without overlap but not (b) because of its 
non-regular boundary. 

Accuracy of a circle covering approximation can be increased 
by increasing the number of cells in a grid. This can be done 
effectively using hexagonal cells as seen in Figure0 Observe 
that (a) has 7, (b) has 19, and (c) has 37 cells in their grids. 
As the number of cells increases, accuracy increases. Note 
also that all these grids span the location space evenly when 
tiled correctly. 

5.4 Canonical Grid Identifiers 

We describe here how the whole globe might be mapped by 
a grid system. The grid granularity must first be fixed. This 
corresponds to a notion of how to quantify when two users 
are considered “nearby”. 

Grid Element labels: Starting from the north pole and 
the Oth longitude passing from Greenwich, one can enumer¬ 
ate the grids having, say, 1 degree width and length until 
reaching the south pole as seen in Figure[9] Note that in this 
grid system, the grid elements are not perfect squares but 
for simplicity we treat them as squares. The grid elements 
then can be uniquely labeled with a simple enumeration. 

latitudes North N 89° N88° 

Pole 



Cell labels: Each cell in a grid element is labeled with an 
identifier that is unique within the grid element. Moreover, 
this labeling is done so that across the whole location space 
each cellSs identifier is unique in an approximate disk cen¬ 
tered at that cell. For instance, in Figure [8] we give two 
examples of cell labels for a portion of the whole plane. 

5.5 Grid Proximity Protocol 

We present the protocol used in proximity testing for Al¬ 
batross. Our method needs only a single comparison (i.e., 
VPET protocol run), independent of the number of approx¬ 
imation cells. The protocol starts as with a grid and cell 
system labeled as in the previous section. One party pro¬ 
vides a cell label to the other party, and both parties are 
able to select grid elements for equality testing. The two 
parties are nearby if and only if the grid elements are equal. 
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Figure 8: Cells are labeled so that any approximate disk is a “Latin Square”. For a grid of square elements composed of 9 cells 
each, any approximate disk has 9 cells with exactly one cell labeled from 1 to 9. For grid elements composed of 7 hexagons, 
any approximate disk having 7 cells has exactly one cell labeled from 1 to 7. 
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Figure 10: Grid Proximity Protocol. 


Figure [10] shows the steps of the protocol. Let l a and Ib 
represent the exact locations of User A and User B, respec¬ 
tively. First, User B computes the cell cb and grid element 
gB corresponding to his location. User A locates the nearest 
cell with label cb- User A selects the grid element contain¬ 
ing this cell, call is qa- User B uses the grid element gs in 
the VPET protocol run with User A. User A compares gs 
to see if it is equal to gA- 

In order to describe the process more clearly, we work through 
the protocol in a toy example. We first consider the case 
where two users are nearby (Figure [TTJi) . Suppose User A 
wants to learn whether B is nearby or not. User B computes 
his grid element to be ”2” and cell label as ”7”. Nearby thus 
corresponds to be inside the circle in Figure llll i. approxi¬ 
mated by the red-colored square. User B sends the cell label 
7 to User A. After User A receives User B’s cell label, User A 
takes the cell nearest to his location with the same label. By 
virtue of the Latin Square property, there is only one such 
cell. User A knows that if User A and User B are nearby, 
User B should be in this cell. Therefore, User A looks up 
the grid element containing this cell and determines that it 
is ”2”. B then sends this grid element to A in the VPET 
protocol. After a run of VPET, User A concludes that User 
B is nearby, although they reside in different grids in the 
grid system. 


After User A gets User B’s cell label, User A assumes that 
User B should be in the closest cell labeled with 7 (i.e., the 
red cell in Figure[lT]j) and sends the respective grid element 
”2” to A in the VPET protocol comparison. Since User B’s 
grid element is ”361”, she concludes that they are not nearby. 



(a) (b) 

Figure 11: Grid Protocol Example. 

Note that the grid system in use can be fixed or can be 
negotiated. To the extreme, any GPS location can be viewed 
as a cell and according to the proximity needed a hexagon 
approximating a circle can be used for the equality testing. 

Note that our system trades efficiency for a reduction in 
privacy for User B. User A gains knowledge of User B’s cell 
label. If User B has little idea of User A’s whereabouts, 
the leakage of the cell label does little harm since there are 
many cells with the same label. However, if User B has 
auxiliary knowledge about User A’s location, then knowing 
the cell label can further narrow down User A’s location. 
In this way, our system shares a weakness of existing work: 
the proximity protocols leak more than strictly desired. If 
User B is actually “nearby”, User A can localize User B to a 
smaller area than an approximate disk around User A. In (a) 
of Figure 0 the 9 comparisons would reveal which individual 
cell User B is in. This is an interesting area for future work 
(see the Appendix in [2T] for an approach to this problem). 


Let us change the location of User B slightly and repeat the 
same experiment. Assume that User A is in the same loca¬ 
tion but User B is located at cell 7 in grid 361 (Figure [TTb l. 
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6. UNIFIED LOCATION PROTOCOL 

As described in Section E21 the active social network of a 
user is considered private information. From the sharing 
























































































habits of a user, one can determine the user’s circles and 
close relationships. One of goals of Albatross is to hide this 
information from the server and other users. To accomplish 
this goal, we use protocol hiding by unifying base protocols. 

To explain the problem in more detail, consider Table [4] 
where we give an example of the sort of information that 
can be inferred by the server. One problem is that the PSP 
and VPET protocols differ in structure. Hence, by virtue of 
routing the traffic, the server can determine whether User 
A’s location sharing granularity for User B is ’’nearby” or 
not. This violates Property PI of our privacy goals. 

Table 4: Server view without unified protocol. The server 
can see whether a user’s preference for other users is nearby 
or not. The server can also see contacts a user is not sharing 
with and which users are offline. 



User A 

User B 

User C 

User D 

User E 


User A 

n/a 

PSP 

invis. 

VPET 

PSP 


User B 

PSP 

n/a 

invis. 

VPET 

PSP 


User C 

VPET 

PSP 

n/a 

VPET 

PSP 


User D 

PSP 

PSP 

PSP 

n/a 

PSP 


User E 

offl. 

offl. 

offl. 

offl. 

n/a 










To address this problem, we describe a Unified Location 
Protocol which masks to the server which protocol (PSP or 
VPET) is being used. This protocol is asynchronous, like 
its underlying base protocols. This protocol is used with all 
contacts. If the preference is to share nothing (i.e., remain 
invisible), an agreed upon dummy location can be shared. 

However, another problem then appears: User A may choose 
to be invisible to User B, which means User A does not 
share location with User B. This preference is supposed to be 
hidden from the server, so A must still checkin to B, or else 
the server would know the preference. However, User B can 
then tell whether User A is offline or just being invisible with 
respect to User B (see Table [5} as presumably User A must 
be online in order to checkin. This problem is more apparent 
with periodic location checkins or “tracking” as opposed to 
sporadic checkins. This violates Property P2 of our privacy 
goals. 

Table 5: User A’s view without caching. Besides the sharing 
preferences of his contacts, User A can also see whether each 
contact is offline, if they checkin periodically. 



User B 

User C 

User D 

User E 


status 

nearby 

invisible 

available 

offline 



Property P2 says that if a user goes offline, his contacts 
should not be aware of this fact. We address this problem 
with a caching scheme used in conjunction with the Unified 
Location Protocol. The user employs the caching scheme 
with the help of the server. The server will be aware that a 
user is offline, and can help the user maintain the illusion of 
still being active to his contacts. 


6.1 Protocol Masking 

By masking the protocol traffic, we hide the user’s active 
social network from the server. For instance, the server can¬ 
not tell that User A is hiding from User B, as opposed to 
some other location sharing preference, such as “Available”. 





Figure 12: Unified Protocol encapsulating both PSP and 
VPET protocols 

We overload specific location coordinates to carry special 
meaning: x„ (= not nearby), x y (= nearby), and xt (= in¬ 
visible). These are dummy location coordinates and used to 
hide communication from the server through the PSP proto¬ 
col. These coordinates, for instance, have longitudes larger 
than 180. The Xi coordinate is used with PSP when a user 
wants to be invisible with respect to another user. 

Figure [12] shows the structure of the PSP and VPET pro¬ 
tocols; the structure of the Unified Protocol simply encap¬ 
sulates both base protocols. There are two protocol actions 
associated with the Unified Protocol: Checkin and Retrieval. 
Checkin is performed by User B to share location with User 
A. Retrieval is performed by User A to see User B’s location. 
Retrieval can be performed anytime after checkin, even af¬ 
ter User B is offline, due to the asynchronous nature of the 
protocol. 

As described in Section [4] we assume A and B share a key 
kAB and they can create keys fci and &2 by encrypting the 
ctr value with kAB■ In the same way, a user can create a 
random bit to encrypt one bit of information. 

Checkin: User B shares with User A 

Before checkin, User B may have done a retrieval of A’s loca- 


























tion information at some point in the past. This information 
is used in the case that A’s preference is PSP and B’s pref¬ 
erence is VPET. If B has no information on A’s location, B 
assumes A is “invisible.” 

Step 1: User B generates a random number for the ctr 
value. He encrypts ctr with Icab • He places the ctr value 
on the server and two encrypted bits. One bit is the pro¬ 
tocol bit for his sharing granularity towards A, representing 
whether B wants to use the VPET or PSP protocol with A, 
i.e., whether B’s location sharing preference for User A is 
“nearby” or not. This is 6b->a- The other bit is A’s sharing 
granularity towards B, stored from the last retrieval of A: 
6a->b- If his sharing preference is “nearby” he also places 
his cell number. 


Table 6 : Step 1 of Unified Protocol. User B stores these 
values on server. 


Field 

Description 

counter 

mandatory 

Protocol bit for B —> A: bs—^A 

mandatory 

Protocol bit for A —> B: bA—>B 

random bit if bs—>A is PSP 

cell number 

random if bg^A is PSP 

B’s vector 

mandatory 


There are three cases: 

A is VPET/B is VPET: B proceeds as in the VPET pro¬ 
tocol and sends to the server vi = rR(xB, 9) + s. 

A is PSP/B is VPET: From B’s last retrieval of A’s lo¬ 
cation, B computes and sends to the server the encrypted 
location vector ( x y 0 ki, ki) or V2 = ( x n 0 fci, fe) depend¬ 
ing on whether A is nearby or not. 

Otherwise: B sends to the server the vector ( xb 0 fci, fc 2 ). 

B may send Xi for xb if he wants to be invisible to A. 

Retrieval: User A gets User B’s location information 


Step 2 : A retrieves ctr and 6b->a and 6a->b- If 6 b->a is 
VPET and 6a->b is out-of-date, A aborts. Otherwise, there 
are two cases: 

A is VPET/B is VPET: A proceeds as in the VPET pro¬ 
tocol and sends the vector vi = R(u , 9) to the server. 
Otherwise: A sends a random vector (bi, 62 ), one that cor¬ 
responds to a location through the vectorization process. 
We cannot use a completely random vector as this would be 
distinguishable from the vector in the other case. 

Step 3: The server computes the vector inner product m = 
(vi, V 2 ) and sends the result to A. 

Step 4 : A decrypts inner product. There are two cases: 

A is VPET/B is VPET: As in the VPET protocol, A 
computes { R(u,9),s )) and if this quantity is equal to m, 
then B is nearby. 

Otherwise: A receives m = bi(xB 0 fcr) + b 2 fc 2 - A knows 
all values except xb and so can compute xb- 


Notes: 

(1) In all cases Server does the same operation in Step 3, an 
inner product, and cannot infer anything from v\ and V2- 

(2) The unified protocol as described only shows B sharing 
with A. In reality, there is also A sharing with B. Both 
directions have their own counters, keys, and preferences. 

6.2 Counter Caching 

Since the server is assumed to be honest-but-curious, there 
is no need to defend against it performing message-replay 
attacks. By allowing the server to replay messages, we en¬ 
able it to reissue advertisements of invisibility on behalf of 
clients who are actually offline. In other words we allow the 
server to help the user maintain the illusion of being online 
to other users. The idea is that Step 1 can be done multi¬ 
ple times by User B in batch, each time generating a new 
counter and specifying the PSP protocol for B’s granularity 
towards A. User B can also do Step 3 in batch, specifying 
Xi (=invisible) for xb and sending v = (xb 0 ki, k2). The 
server keeps a conceptual table for each user, as in Table [7] 
At the end of the protocol, User A sees that User B is invis¬ 
ible and cannot tell if User B is actually online or not. After 
a counter value has been used, the corresponding row in the 
table can be deleted. 

Table 7: User’s counter cache. This information is used by 
the server to help the user checkin even when offline and 
thus maintain the illusion of being online. The checkins 
the server makes on behalf of the user corresponds to the 
“invisible” preference; hence all contacts will see this user as 
“invisible.” 


Counter 

Protocol bit 

Encrypted location 

Ctrl 

E(PSP) 

vi 

ctr2 

E(PSP) 

v 2 

ctr3 

E(PSP) 

V3 





If the user is actually online and wishes to change his shar¬ 
ing granularity, he can generate a new counter value and 
prepend a new row to his counter cache table. 

6.3 Privacy Analysis with Unified Protocol 

In Tables [ 8 ] and [9] we see the end result of our unified pro¬ 
tocol. The server sees only whether the user is on or off. 
The user sees only the sharing granularity of his contacts 
towards himself, not whether they are online or offline. 

Table 8 : Server view with unified protocol. The server sees 
only whether a user is online or not, as well as the set of 
contacts for each user. Nothing about the preferences for 
each contact can be seen by the server. 



User B 

User C 

User D 

User E 


status 

on 

on 

on 

off 



7. SYSTEM PROTOTYPE 

Albatross is realized as a working research prototype and 
we describe the implementation here. With this prototype, 
we demontrate that the performance of Albatross is suitable 
for real-world deployment and raises no scalability concerns. 
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Table 9: User A’s view with unified protocol and caching. 
User A can see the preferences of his contacts towards User 
A, but cannot tell if users are invisible or simply offline. In 
this way, his contacts maintain plausible deniability about 
being offline versus purposefully hiding from User A. 



User B 

User C 

User D 

User E 


status 

nearby 

invisible 

available 

invisible 



The overhead compared to a non-private system is on the 
order of the average number of contacts. 


Albatross Architecture 



Note that we relied on a public/private key pair on the An¬ 
droid devices in the Diffie-Heilman key exchange. These key 
pairs were generated as part of Albatross installation. The 
client also contains a location handler which gets location in¬ 
formation from the device via the GPS system. Correspond¬ 
ing to the GPS location, the protocol handler determines the 
grid and cell values if using the VPET protocol. 

7.3 Performance 

We measured the total time for a retrieval on a Samsung 
Galaxy S III smartphone having a 1.5 GHz dual-core Qual¬ 
comm Krait processor running Android 4.0.4. The time for 
a checkin should be even less. Our server was an Ubuntu 
12.04 LTS instance in the Amazon Elastic Cloud (EC2), run¬ 
ning on an AMD 64 with 1.7 GB of memory. As our server 
was dedicated to only Albatross, we picked a small instance 
(ml.small) providing a single EC2 compute unit. 



10 100 200 300 400 500 

Number of contacts per user 


Figure 13: High-level Albatross architecture. The server 
is built on top of Apache/PHP/MySQL. The client is an 
Android application with persistent storage in SQLite. 

7.1 Server-side 

We used Apache/PHP and MySQL as the backbone of our 
server-side implementation (see Fig. H3ll . The main MySQL 
tables are a users table that contains profile data and a con¬ 
tacts table that contains a list of contacts (i.e., edges in the 
social graph) in the system. Each edge in the contacts table 
contains protocol information for both protocol directions, 
for example, User A’s sharing with User B and also User 
B’s sharing with User A. Registration and authentication is 
through a username and password. 

7.2 Client-side 

We developed an Android client for Albatross. This client 
application keeps sharing preferences and keys for each con¬ 
tact in the native Android SQLite database. SQLite gives 
us a self-contained SQL database to store contact data even 
after Albatross is stopped. 

The client consists of a protocol handler that determines 
the protocol to use and performs the Unified Protocol steps. 
The protocol handler uses the Spongy Castle cryptographic 
library, a repackaging of the standard Bouncy Castle cryp¬ 
tographic libraries explicitly for the Android platform. Al¬ 
batross employs Spongy Castle for AES and Diffie-Hellman 
key exchange calculations. 


Figure 14: Retrieval time for various numbers of contacts. 

Recall that in the Unified Protocol, users share some loca¬ 
tion - real, approximate, fake or dummy - with all of their 
contacts. The Unified Protocol has two halves, a checkin and 
a retrieval. For experimental purposes, we placed checkin 
data on the server and executed the Unified Protocol for 
retrieval (the more complex and time-sensitive half of the 
protocol) in batch. Location information for all contacts 
was downloaded, corresponding to a user finding where all 
his friends are. We assumed that users have around 500 con¬ 
tacts total. Averaging over 20 retrievals, we found that it 
took about 1.1 seconds for a user to retrieve location infor¬ 
mation for all 500 contacts. In order to see the effect of the 
number of users, we repeated our experiments for various 
numbers of contacts as illustrated in Figure[l4]and the time 
scales about linearly with the number of contacts. 

One question is how our privacy requirements effect the total 
amount of storage and user/server workloads. Compared to 
a simple location uploading for a trusted server, as in Google 
Latitude and Foursquare, Albatross requires protocol inter¬ 
action with each contact (through the server) rather than an 
interaction with just the server. Also, the Unified Protocol is 
more complex than a simple upload. In Tables [TUI and fill we 
give a theoretical description of the performance and storage 
costs of the Unified Protocol in terms of N, the number of 
a user’s contacts. For a trusted server, each checkin is sim¬ 
ply the uploading of location information to the server. For 
Albatross, each checkin involves one symmetric encryption 
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and random number generation on the client side for each of 
the user’s contacts. Each retrieval requires two client-server 
interactions. Since the number of contacts in a social net¬ 
work generally runs in the several hundreds ESI, as a rough 
estimate the performance and storage costs for Albatross 
can be on the order of N times more than for a non-private 
system. 

Table 10: Summary of Albatross computation costs for one 
user’s checkin and retrieval. In Albatross, checkins must be 
performed per contact. The checkin is also more involved, 
with a symmetric encryption and random number genera¬ 
tion per contact. The retrieval using Albatross involves two 
client-server interactions, the server computes a different in¬ 
ner product for each contact, and each inner product must 
be decrypted. Hence, the computation costs for Albatross 
scale with the number of contacts N. Below, C represents 
a constant cost independent of N. 


Protocol 

Client cost 
(Retrieval) 

Server 

cost 

Client cost 
(Checkin) 

Unified 

0{N) 

O(N) 

0{N) 

Non-private 

C 

C 

C 


Table 11: Albatross storage requirements per user. In Alba¬ 
tross, clients store a key (16 bytes) and location preference 
(1 byte) for each contact. Servers store state information 
for the Unified Protocol (17 bytes, see Tabic [6]) and also, 
say, 10 cache values of state information. In a non-private, 
trusted server protocol, servers store the user’s location and 
location preferences per contact. 


Protocol 

Client 

storage 

Server 

storage 

Unified Protocol 

(16 + 1 )N 

17 * 11 * N bytes 

Non-private Protocol 

0 

8 + N bytes 


8. RELATED WORK 

Existing production location sharing systems with a trusted 
server include Foursquare [4], Google Latitude [6j, Apple’s 
Find My Friends [3], and Glympse [5]. There has been work 
on location sharing systems that enhance privacy through an 
untrusted server. The work by Narayanan et al. m concen¬ 
trates on a particular type of location sharing, the “nearby” 
sharing granularity. We aim for a more complete system 
that includes different granularities of location sharing and 
address the issue of how to hide these granularities from the 
server. Zhong et al. [23], Mascetti et al. [Hill], and Nielsen 
et al. [22] also focus on the “nearby” sharing granularity. 

Private versions of other types of social networking systems 
with an untrusted server have also been studied. Cristofaro 
et al. m studied micro-blogs, specifically Twitter. Their 
system is analogous to ours in that they attempt to pro¬ 
vide the expected core micro-blogging services, and yet hide 
tweets, hashtags, and followers from the server. Rieffel et 
al. [23] study presence systems, in which a user’s presence 
status (“in building”, “in office”, “has visitor”, etc.) is hid¬ 
den from the server. There is a large body of work studying 
recommender systems with untrusted servers; early work in 
this area was performed by Canny Ell- 


Location privacy in general is a well-studied topic. Problems 
such as anonymity and obfuscation of location data is one 
area of concentration. Krumm ESI provides a good survey 
for this area. Another area of study is user preferences for 
location sharing, for instance, see Ezug. 

9. CONCLUSION 

We present Albatross, a new privacy-enhanced location shar¬ 
ing service. We designed a complete system with a full se¬ 
lection of location sharing granularities. Such a complete 
system may reveal social networks, i.e., individual social cir¬ 
cles, through analysis of individual sharing granularities over 
time. Previous work has in general concentrated on a par¬ 
ticular sharing granularity, such as “nearby”. 

In our design of Albatross we analyse desired privacy prop¬ 
erties of a location sharing service and achieved location pri¬ 
vacy from the service provider and social network privacy. 
The level of privacy attained is not complete, but seems rea¬ 
sonable given the practical considerations of keeping traffic 
at a reasonable level. We achieved location privacy through 
lightweight cryptographic protocols and social network pri¬ 
vacy through protocol unification and masking. A working 
research prototype of Albatross showed performance is ac¬ 
ceptable. 

There are numerous opportunities to improve and extend 
Albatross. For example, privacy may be further improved 
by protecting a user’s offline/online patterns from the server 
through a proxy architecture. Also, we plan to investigate 
how a system such as Albatross can support services such as 
advertising and location recommendation. After all, the ap¬ 
peal of holding consumer location information is the poten¬ 
tial increase in precision and relevance of recommendations 
and targeted ads. We believe advertising and location rec¬ 
ommendation systems are still possible with Albatross but 
of course will have to be re-designed. 
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